IBIS Macromodel Task Group Meeting date: 26 June 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - The meeting scheduled for July 3rd is cancelled (see below). ------------- Review of ARs: - Michael M. to submit his "Enabling [Rgnd] and [Rpower] for Input Model_type" v2 to the Open Forum as a BIRD. - Done, BIRD195. - Arpad to send an email to the Open Forum noting that the ATM had voted to submit BIRD195. - Done. - Mike L. to update the IBIS 6.1 known issues list to include adding Value entries to the PAM4 thresholds Usage Out example on pg. 235-236. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 19 meeting. Michael M. moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: Meeting on July 3rd: - Arpad asked if we should cancel the meeting. Walter moved to cancel the meeting scheduled for July 3rd. Michael M. seconded. There were no objections. Enhanced C_comp Modeling: - Randy reviewed the latest version of his proposal (emailed to ATM on June 12). He noted that he had not received any new feedback. Randy noted that the text for [C_comp_Corner]'s Usage Rules had been modified to align with the changes BIRD191.2 made to the Si_location and Timing_location descriptions. BIRD191.2 introduced clarifications to these locations that came out of BIRD189. This proposal incorporates those changes, and notes that: The "Die" location refers to the Buffer_I* terminal(s) of a [C_Comp_Model] if [C_comp_Model] is present and includes Buffer_I* terminal(s). Randy noted minor changes to the description of series elements in [C_comp_Model]. The changes clarify that a series element could exist between the buffer I/O terminal and the "active buffer elements", to explain the location of on-die interconnect at the "buffer level." Randy noted, however, that he was leaning toward removing this ability to add a series element between the active buffer element (I/V location) and the buffer I/O terminal. Referring to Figure X., he noted that we might only want to allow a series element between the buffer I/O terminal and the input. It would simplify this BIRD, and anything more complicated might not be necessary since on-die interconnect is available with BIRD189. Bob noted that this would be a restriction - there would be no C_comp_Model with a series element for anything other than an input or terminator or the input path of an I/O. Randy noted that Number_of_terminals shall always be 2 or greater, because a reference terminal is always provided. The text states that the IBIS-ISS subcircuit terminals shall not contain an ideal reference node (SPICE node 0, etc.). Randy noted that the preference is that node 0 not appear anywhere in the subcircuit. But in keeping with BIRD189's decisions, having node 0 inside the subcircuit is not explicitly prohibited. Upgrading the input thresholds/measurement info to include eye diagram specs: - Walter moved to untable this topic. Michael M. seconded. There were no objections. Walter introduced the topic and briefly reviewed some information on the web including a Micron DDR4 overview. Walter suggested we should have a BIRD to enhance IBIS and add JEDEC DDR3/4/5 measurement metrics, and that we could decide which metrics to include. He noted that most EDA vendors have some way of addressing these metrics, and we could standardize. Arpad noted that we had discussed this previously and usually decided to just point to some outside sources instead of inventing our own syntax and building it into IBIS. Michael M. noted that we can't rely on having a standards organization for every interface. He noted that in the past we had stumbled when one model might be used for multiple interfaces. If, for example, the thresholds associated with one type of interface were built into a [Model], then that [Model] can't be used for other interfaces. Walter noted that for SERDES one buffer Model could be for various standards. DDR4 and DDR5 are different in that respect. If you're a compliant DDR4 device at a particular speed grade, then there is an associated value for VdIVW for that speed grade. So a tool could have the logic to pick that value. But it would be nice to have those fundamental values as IBIS params. For example, VdIVW could be a parameter, and it could be relative to some vref. Randy noted that the issues Walter was describing led to some modeling inefficiency. For example, thresholds defined per bit rate. We need to define those thresholds differently for each frequency range. We might have a DQ model good for 1600MBps up to 3200MBps, but if you can only specify one threshold value per model then it becomes very inefficient. You have to copy and paste the same model over and over just to change thresholds. Michael M. asked if this could be handled with something like a Threshold_Selector (similar to Model_Selector). Randy said you'd need a way to indicate the frequency range. Walter noted that SiSoft had implemented similar things using an "include" file containing all the DDR4 thresholds in one file, for example. He said SiSoft would be willing to share the methods they were using. Arpad noted that another option might be to use a parameterized [External Model] that could pass back values based on an input parameter. Walter said the bottom line is whether everyone, particularly the EDA tool vendors, agree this is something worth pursuing. Arpad asked if Walter were going to draft a proposal. Walter said he first wanted to make sure we had consensus that this was worth pursuing. Walter took the AR to send an email to ATM introducing this topic and noting it will be discussed next meeting. - Walter: Motion to adjourn. - Bob: Second. - Arpad: Thank you all for joining. AR: Walter to send an email to ATM announcing the DDR thresholds discussion topic. ------------- Next meeting: 10 July 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives